The disclosure of this patent document contains material that is subject to copyright protection. The owner thereof has no objection to facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The invention concerns digital data processing for process control and, more particularly, novel mechanisms for assigning and managing object references in process control systems with distributed object management systems.
The art of digital data processing has progressed considerably in its first forty years. Well known are the advancements in computer hardware, for which ever more powerful microprocessor is the best known example. No less impressive is the evolution in computer software.
In the earliest computer programs, there were no abstractions. Programming instructions and data alike were coded directly in the forms in which they were to be executed by the primitive processors, to wit, as strings of ones and zeros. With the vent of programming languages such as FORTRAN, it became possible to code instructions as words and symbols. Data could be named and grouped into arrays to facilitate their reference.
Through use of the early languages, and with initial improvements in hardware, computer programs came to solve increasingly difficult tasks. Unfortunately, the programs themselves became too complex for trouble-shooting, maintenance and upgrading. Modularity, which was then coming to influence other technologies, came to the aid of the software arts as well.
Using block programming languages and techniques, programmers began to write long sequences of instructions as smaller independent segments that could be designed, tested and maintained separately. These segments, especially those packaged as subroutines, often did not share a common pool of data but, rather, passed information back and forth on an as-needed basis.
Modularity also impacted the manner in which data was referenced. Data constructs became richer, reflecting increased use of computers outside the once traditional confines of mathematics and engineering. Simple data arrays gave way to records and other structures that permitted the agglomeration of varying types of data, typically, matching the diversity of attributes in the real-world objects that they modeled.
The trend toward modularity brought more far-reaching changes with the advent of object-oriented programming. According to this practice, which is just now beginning to overtake the industry, data are packaged in structures that also include the specific procedures that act on them. These structures, or objects, can be transferred along with their attendant procedures, thereby, improving the instruction/data coherency and facilitating trouble-shooting, maintenance and updates.
The growth of distributed computing over the Internet and corporate intranets has made it desirable to utilize objects among diverse computer systems, often operating at great distances. The Object Management Group, a consortium of computer companies, responded to this need by establishing CORBA, a protocol for distributed object management. Using CORBA protocols, a xe2x80x9cclientxe2x80x9d computer, e.g., in Japan, can access an object resident on a xe2x80x9cserverxe2x80x9d computer in Massachusetts, all via the exchange of CORBA-specific request and response packets.
CORBA can be used in a wide variety of applications, including process control. The central computer at a manufacturing facility or refinery, for example, can employ the protocol to control and monitor the status of substations or individual microprocessor-based controllers disposed about the facility. Moreover, corporate oversight may be attained via a remote computer, e.g., at corporate headquarters, which can use the protocol to obtain information from the plant""s central computer.
Though CORBA represents a much welcomed advance to the digital data processing arts, certain applications can unnecessarily overburden it. This may be the case, for example, in process control, or other complex software application, where servers must provide potential access to large numbers of objects.
In process control, for example, the central computer of a manufacturing or refining facility may oversee an average of 25 control processors, each of which can manage roughly 75,000 control blocks, having approximately 50 parameters apiece. To provide xe2x80x9cclientsxe2x80x9d (such as a computer corporate headquarters) full access to plant operations, the central plant computer must potentially provide access to 3,750,000 objects, that is, the objects representing all of the processors, control blocks and parameters. To add the insult of underutilization to the injury of enormous capacity, the clientsxe2x80x94in practicexe2x80x94are likely access only a few hundred or thousand of those objects during any session. According to the conventional CORBA approach, administrative structures (such as binding table entries and object references) necessary to service requests to the 3,750,000 objects would be created regardless.
In view of the foregoing, an object of the invention is to provide improved digital data processing systems and, more particularly, improved methods and apparatus for managing object references in distributed object systems.
A more specific object of the invention is to provide such methods and apparatus as are suited for use in managing object references in CORBA-compatible distributed object management systems.
Yet a further object of the invention is to provide such methods and apparatus as reduce the resource and overhead requirements for implementation of distributed object management, e.g., on systems where servers are called upon to provide access to large numbers of objects.
A related object of the invention is to provide such methods is to provide such methods and apparatus for use in providing distributed object management for process control systems, and other complex systems.
The foregoing and other objects are met by the invention, which provides in one aspect improvements on digital data processing systems with distributed object management. These systems are of the type having servers and, more particularly, object request brokers (ORB""s) that route requests generated by one or more clients to implementation objects maintained by a server application. Routing is based on a binding table (or other such store) that identifies dispatching procedures, or xe2x80x9cskeletons,xe2x80x9d that invoke requested services on implementation objects specified in the request. Such systems may be CORBA-compatible, though the improvements provided by the invention are applicable to distributed object management systems having other architectures, as well.
The improvements are characterized by the utilization of a single entry in the is binding table (or other such store) to route requests to a plurality of different. implementation objects (or, for sake of convenience, xe2x80x9cimplementationsxe2x80x9d) maintained by the server. In a related aspect, the improvements can be characterized as providing an CORBA-compatible ORB or, more particularly, (basic) object adapter (OA), that permits requests to be routed to implementations that are not listed in the binding table.
The invention provides systems as described above in which at least selected requests generated by the client include a pair of object identifiers (OID""s). The first OIDxe2x80x94which can be contained in the object reference supplied the server and copied into the requestxe2x80x94is used by the server ORB and, more particularly, the OA, to locate an entry in the binding table. The second OIDxe2x80x94which the client can obtain from the component portion of the server-supplied object referencexe2x80x94can identify the specific implementation from which services are requested.
The OA, according to further aspects of the invention, can match the first OID contained in a request (e.g., in the server-supplied object reference) against the binding table. A matching entry specifies a first dispatching procedure (e.g., a skeleton associated with a block implementation identified by the first OID) to which the OA applies the request. That first dispatcher, in turn, applies the request to a second dispatcher (e.g., a skeleton associated with the implementation identified by the second OID in the request). Like the second OID, the identity of that skeleton can be contained in the request.
Once in receipt of the request, the second skeleton applies it to the implementation identified by the second OID. For example, the skeleton can decode, or xe2x80x9cunmarshall,xe2x80x9d any parameters contained in the request and pass them to the specified procedure of the implementation.
According to still further aspects of the invention, the first and second OID""s in a request correspond to addressable locations, e.g., memory addresses, of first and second implementations maintained by the server application. The correspondence between the first OID and the addressable location of the first implementation (e.g., a block implementation) can be reflected in the binding table, each entry of which lists an OID, a corresponding implementation address, and a pointer to the dispatch procedure or skeleton for that implementation. Though corresponding entries can be provided in the binding table for the second OID""s, they need not bexe2x80x94since the invention permits requests to be routed to implementations identified by the second OID""s, without requiring a corresponding entries in the binding table.
According to further aspects of the invention, the implementations identified by the first and second OID""s of a request are related in such a way that their respective addressable locations differ by a predetermined addressing offset. For example, the first and second implementations can comprise portions of the same object construct instantiated on the server. In a process control application, for example, an implementation identified by a second OID can comprise a parameter-represeritative object (i.e., parameter object) associated with an entry point contained on a block-representative object (i.e., block object) identified by a first OID. In this regard, the implementation identified by the first OID is seen to have an aggregating or xe2x80x9cparentxe2x80x9d relationship between one or more implementations that are xe2x80x9cchild objectsxe2x80x9d or xe2x80x9csub-objectsxe2x80x9d potentially referenceable by second OID""s. As a consequence of this parent/child, object/sub-object, or aggregation relationship between the implementations identified by first and second OID""s, the second OID included in an object reference can be determined from the memory address for the implementation identified by the first OID.
In further aspects of the invention, the server capitalizes on this by deferring, until necessary, creation of the administrative structures required to service requests issued to the second implementation (e.g. those representing parameters). Thus, even though those implementation objects may come into existence at the same time as their parent implementations (e.g., those representing blocks), no object reference nor binding table entry need be created until a client signals a desire to make access, for example, by requesting service from a corresponding accessor method on the parent implementation.
To this end, in a related aspect of the invention, the server generates a first object reference corresponding to the first implementation. This can be accomplished with a conventional CORBA xe2x80x9cbindxe2x80x9d operation, which assigns an OID to the implementation and creates an object reference containing that OID, along with certain typing and networking-related routing information. At the same time, the bind operation creates an entry in the binding table. This lists the OID assigned to the implementation, the location of the implementation, and a pointer to its associated dispatching procedure or skeleton. Upon binding the first implementation (e.g., a block implementation object), the object reference created by the server ORB can be copied to the client, thereby, enabling it to issue requests to that implementation.
To enable a client to issue a request to an implementation that is not listed in the binding table (e.g., a parameter implementation object), the server creates a xe2x80x9cspecialxe2x80x9d object reference that contains two OID""sxe2x80x94one for the non-listed implementation and one for the listed aggregating implementation. While this can be done concurrently with creation of the object reference for the corresponding listed implementation, it can be deferred until a client signals the desire to make requests to the non-listed implementation.
The server can create such a special object reference by duplicating the object reference for the aggregating implementation and appending to that object reference the OID of the non-listed implementation. Since the duplicated object reference already contains a first OID, e.g., that of the listed implementation, appending that of the non-listed implementation results in a object reference containing two OID""s. In the parlance of CORBA, the second OID is appended as a component to the object reference. Along with it can be included the address of the dispatching procedure or skeleton for the non-listed implementation. In implementations where the listed implementation has a parent or aggregating relationship to the non-listed implementation, the second OID can be determined by an address computation, e.g., by adding a predetermined offset to the memory address associated with the first OID.
By passing an object reference for a non-listed implementation to the client, the server enables that client to issue requests to that implementation. To this end, the client includes both OID""s in its requests (e.g., by copying the first OID, along with the object reference, directly into the request and appending the second OID from the component portion of that object reference). When received by the server, routing of those requests proceeds in the manner described above.
Still further aspects of the invention provide methods digital data processing systems with distributed object management paralleling the operations described above.